IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) and Session Description Protocol (SDP) to set up and control calls or sessions between user terminals (or user terminals and application servers). Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
A User Equipment (UE) can access the IMS by attaching to an access network. If the access network is a Packet Switched (PS) network, such as an Evolved Packet Core (EPC)/Long Term Evolution (LTE) access network, an IMS session can be set up by the UE using SIP signalling. However, many existing access networks operate only using Circuit Switched (CS) technology, and procedures are well established for dealing with the provision of media and services to a UE accessing the IMS via a CS access network.
There are many occasions when during a call/session it is required to transfer or hand over the call/session from one access network to another. Single Radio Voice Call Continuity (SRVCC) is described in 3GPP TS 23.237 and 3GPP TS 23.216, which specify procedures for handover of a voice call from a PS access to a CS access (e.g. transfer of a VoIP IMS session from an evolved UMTS Radio Access Network—E-UTRAN—to a UTRAN or GSM Edge RAN-GERAN). These technical specifications have also been extended to allow handover of a voice call from a CS access to a PS access. When an emergency call is made to an emergency centre or Public Safety Access Point (PSAP), special procedures are applied to ensure that the call is correctly routed and not interrupted. An emergency call that is established over the IMS is anchored in the IMS entities that serve the UE through the access network at which the UE was attached when the emergency call was established. The specified procedures ensure that at handover the call continues to be routed through those same IMS entities. As part of those procedures an emergency Public Data Network (PDN) connection is established.
However, in some situations it is possible for a UE to perform a so-called UE-undetected emergency call, i.e. a call that is supposed to be routed to an emergency centre, but where the UE is not aware of the emergency call and does not take any specific actions when setting up the call. The Proxy-Call/Session Control Function (P-CSCF) will detect that this is an emergency call from the SIP INVITE sent from the UE to set up the call, because it includes an emergency number. But, because the Invite is sent over a normal registration (and not an emergency registration), and because the INVITE Request-URI does not include an SOS-URI parameter (which it should do to make it clear it is an emergency call) then the P-CSCF will know that it is a UE-undetected emergency call.
The current procedures specify that the P-CSCF may allow the network to continue the emergency call establishment even if the P-CSCF detects this to be an UE-undetected emergency call. In that case, the P-CSCF indicates to the UE that this is an emergency session. In such cases no emergency PDN connection is established prior to the establishment of the call and so the Mobility Management Entity (MME) is not aware that it is an emergency call.
However, if a SRVCC handover of the UE-undetected Emergency Call is performed, the MME and the Mobile Switching Centre (MSC) will not know that the call is an emergency call and the handover will fail. This is because the MSC will use a regular Session Transfer Number for SRVCC (STN-SR) provided by the MME to route the session transfer request. The use of the regular STN-SR will not route the call from the MSC via the IMS network in which the call is anchored.